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SUMMARY 


PROBLEM:  The  development  of  concepts  and  algorithms  tor  simulating  lor  training, 
the  performance  characteristics  of  both  Thermal  Imagery  Systems  (T1S)  and  Low  Light 
Level  Television  Systems  (LLLTV)  is  critical  to  current  and  future  simulator  acquisi- 
tion programs.  The  development  of  this  technology  will  rely  on  Computer  Image  Gen- 
eration (CIG)  with  emphasis  upon  data  base  characteristics  and  algorithms  incorpor- 
ated as  part  of  system  processing.  The  development  and  validation  of  this  technology' 
must  be  accomplished  under  static  as  well  as  dynamic  conditions  typical  of  that  im- 
posed upon  a real-time  full  mission  weapon  system  simulator. 

APPROACH:  The  approach  employed  by  A PURL  consisted  of  the  development  of  a 
system  with  an  optimum  combination  of  flexibility  with  rapidity'  of  simulation  update  to 
permit  a wide  variety  of  techniques  to  be  investigated  under  both  static  and  dynamic 
conditions.  The  system  was  designed  to  permit  control  over  key  simulation  param- 
eters and  enable  flexibility  with  respect  to  both  data  base  and  algorithm  development. 
The  capability  of  the  A FURL  Simulation  and  Training  Advanced  Research  System 
(STARS)  was  incorporated  to  the  maximum  extent  and  was  further  augmented  through 
the  use  of  Digital  Equipment  Corporation  (DEC)  minicomputers  together  with  special 
purpose  hardware  to  provide  the  speed  with  minimal  compromise  of  flexibility.  The 
special  purpose  hardware  performed  otherwise  time-consuming  functions  of  edge 
smoothing,  transfer  function  generation  and  sensor  noise.  However,  the  hardware 
was  designed  to  permit  control  over  degree  of  smoothing,  type  of  transfer  function, 
and  percent  noise  through  software.  A core  memory  was  provided  with  sufficient  size 
to  hold  a full  frame  of  video  information.  An  Ampex  video  disk  and  tape  unit  were  pro- 
vided so  that  individual  frames  could  be  accumulated  on  the  disk  and  transferred  to 
tape  to  permit  dynamic  sequences  to  be  recorded  for  subsequent  playback  in  real  time. 
A data  base  was  provided  which  included  about  2500  square  miles  in  the  vicinity  of 
Las  Vegas.  Both  culture  and  terrain  data  as  stored  in  Defense  Mapping  Agency  (DMA) 
source  data  were  included  in  the  data  base.  In  addition  to  this,  ten  special  target  areas, 
which  included  runway,  power  plant,  and  power  lines  were  provided  to  supplement  DMA 
source  data. 

RESULTS:  The  system  was  tested  by  generating  both  static  and  dynamic  sequences 
over  many  portions  of  the  data  base.  Dynamic  sequences  of  three-minute  duration 
were  generated  with  no  perceptible  scene  discontinuities  during  the  transition  irom 
disk  to  tape.  Update  rates  for  individual  frames  covered  from  10  to  30  seconds  per 
frame,  depending  upon  number  of  edges  contained  in  the  scene  and  degree  of  smoothing 
employed.  Scenes  were  successfully  generated  employing  many  combinations  of  edge 
smoothing,  transfer  function  and  noise. 

CONCLUSIONS:  The  system  as  developed  under  this  effort  has  demonstrated  usability 
as  a research  tool  for  conceptual  and  algorithm  development  applicable  to  TIS  and 


1.1.1. TV  simulation  tor  training,  Tin  flexibility  afforded  through  use  of  software 
emulation  and  variety  of  both  terrain  and  culture  which  can  be  stored,  processed  and 
displayed  should  provide  a very  versatile  and  cost-effective  tool  for  research  purposes. 
It  is  anticipated  that  system  capability  will  enable  its  use  to  support  development  ac- 
tivities in  the  area  of  texture  synthesis  for  improving  current  technology  as  well  as 
new  concept  developments  employing  non-linear  techniques. 
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1.0  INTRODUCTION 


( 


The  development  of  airborne  infrared  and  low  light  level  television  systems  has  pro- 
gressed to  the  extent  that  these  systems  are  currently  in  use  in  the  B-52  weapon  sys- 
tem. Furthermore,  these  sensor  systems  are  likely  to  be  used  in  future  weapon 
systems. 

There  is  at  present  no  efficient  and  cost-effective  capability  for  training  crews  who 
must  understand  and  operate  these  sensor  systems.  Such  training  must  be  based  upon 
a knowledge  of  the  capability  inherent  in  present  technology  for  satisfying  this  require- 
ment and  any  subsequent  development  which  may  be  required. 

As  a result,  the  Air  Force  Human  Resources  Laboratory  (A FURL)  conducted  explor- 
atory programs  which  gained  insight  into  the  performance  characteristics  of  these 
sensor  systems  and  established  potential  suitability  of  computer  image  generation  tech- 
nology for  satisfying  the  performance  criteria  imposed  upon  the  hardware  simulation 
system.  These  programs  included  cultural  features  only  and  were  limited  to  static 
situations  from  the  standpoint  of  the  simulation  and  the  output  scenarios.  General 
Electric  supported  this  exploratory  effort  under  Contracts  F33615-74-5H11 
and  F33615-75-C-5243. 

As  a next  step,  AFHRL  initiated  an  advanced  development  program  to  expand  simula- 
tion capability  to  permit  generation  of  a dynamic  simulation.  The  goal  was  the  devel- 
opment of  a system  in  which  simulated  flight  maneuvers  could  be  conducted  over  a 
limited  gaming  area  containing  natural  terrain  and  cultural  features  while  recording 
the  output  scenarios  during  this  simulation.  Time  between  updates  was  to  be  mini- 
mized so  that  recordings  could  be  made  in  nonreal  time  with  playback  in  real  time. 

In  this  manner  data  base  information  and  algorithms  could  be  evaluated  under  dynamic 
simulation  conditions  representative  of  real-time  systems. 

A study  program  was  initiated  to  determine  on  a competitive  basis  the  best  design  lor 
a system  consistent  with  cost,  maintainability,  flexibility,  and  feasibility.  The  study 
programs  were  to  result  in  a complete  definition  of  all  general  purpose  and  special 
purpose  hardware  required  together  with  requirements  for  software  programs  to 
effect  the  simulation.  The  study  was  to  definitize  the  hardware  and  associated  inter- 
face required  between  hardware  components  and  for  integration  into  the  existing 
A FHRI.  facilities. 

The  study  program  was  completed  and  the  General  Electric  Company  was  selected  to 
perform  the  follow-on  effort.  This  follow-on  effort  covers  the  fabrication  and  imple- 
mentation of  the  system  defined  by  General  Electric  under  Contract  F33f>15-75-C-T>2S7. 
This  previous  work  was  also  under  the  direction  of  Mr.  William  1..  Foley  ot  the  Sim- 
ulation Techniques  Branch  of  the  Air  Force  Human  Resources  Laboratory  at  Wright- 
Patterson  Air  Force  Base. 
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The  effort  performed  under  Contract  FdM  15-7H-R  0059  and  described  in  this  report 
encompassed  the  design,  fabrication,  and  implementation  of  the  sensor  simulation 
system  selected  by  AFllUl.  from  the  part  one  study  phase.  The  system  implementa- 
tion included  the  installation,  checkout,  ami  integration  of  the  General  Fleet  ric  tie  signet 
system  into  the  Simulation  ami  Training  Advance  Research  System  (STARS)  simulation 
facility  at  AMIRI,. 


The  tasks  performed  included  the  purchase  of  general  purpose  computational  and  video 
recording  equipment,  fabrication  of  special  purpose  hardware,  and  the  adaptation 
development  ot  software  to  provide  the  sensor  simulation  programs  that  are  compatible 
with  the  hardware  configuration.  The  total  system  is  capaole  of  operating  in  a dynamic 
mode,  i.e.,  the  time  intervals  between  successive  scenarios  are  sutticiently  short  so 
that  playback  of  successively  recorded  scenes  can  be  accomplished  at  real-time  rates. 
The  simulation  includes  a data  base  which  permits  simulated  flight  profiles  in  any  de- 
sired direction  over  the  gaming  area.  The  total  effort  included  data  base  preparation 
troni  Detense  Mapping  Agency  (DMA)  source  data  and  a simulation  program  to  extract 
data,  establish  priorities,  perform  data  transformation,  insert  the  elfect  ot  atmos- 
phere, and  transfer  characteristics  of  sensor  system  and  prepare  video  for  recording 
and  display.  The  equipment  involved  is  interfaced  so  that  data  may  be  translerred  be- 
tween general  purpose  and  special  purpose  hardware  and  video  recording  and  display 
hardware.  The  total  system  is  configured  to  enable  maximal  use  of  general  purpose 
computational  equipment  consistent  with  system  flexibility  and  rapid  simulation  update. 


The  basic  approach  used  in  this  program  was  developed  during  the  Airborne  Fleetro 
Optical  Sensor  Simulation  (A FOSS)  design  definition  phase  (Contract  Fddtilhf 75-C-52S7) 
and  documented  in  the  final  report  for  that  program  phase.  While  modifications  to  the 
initially  defined  approach  were  made,  by  incorporating  optional  capabilities  to  better 
meet  overall  program  objectives,  the  basic  approach  is  still  directly  patterned  after 
the  hardware  organization  employed  by  General  Flectric  in  the  design  ot  real-time 
Computer  Image  Generation  (Ch'.t  systems.  This  is  an  important  teature  ot  the  system, 
in  that  it  ensures  that  all  algorithms  and  techniques  employed  can  be  implemented  in 
practical  real-time  systems.  This  important  feature  was  also  retained  in  the  earlier 
all  software  simulation  model  developed  under  Contract  FddO  15-7-1 -a  101  by  F-eneral 
Flectric. 


Thus,  the  primary  thrust  of  this  effort  was  to  reduce  the  per  scene  processing  time 
exhibited  by  the  earlier  all  software  model  to  the  minimum  level  consistent  with  re- 
taining the  major  flexibility  characteristics  of  the  software  model.  The  method  em- 
ployed involved  a threefold  approach.  S|vcial  hardware  logic  modules  were  designed 
to  perform  those  computational  functions  that  are  most  time-consuming  on  general 
purpose  computers  and  where  flexibility  could  Ik*  retained  with  a hardware  implemen- 
tation. The  computational  capacity  ot  the  STARS  Sigma  f>  was  augmented  by  adding 
two  DDF  1 1 ).»  computers  to  the  facility  and  allocating  general  purpose  computational 
functions  among  the  three  machines.  At  the  same  time,  many  algorithms  were  molli- 
fied and  or  reprogrammed  to  achieve  more  etticient  execution  on  the  res)x*ctive 
machines. 


2.0  TECHNICAL  DESCRIPTION 


2. 1 IMP l EMENTATION  OVERVIEW 

In  addressing  the  implementation  of  this  sensor  simulation  program , it  is  convenient 
to  consider  the  program  in  two  major  parts.  One  part  is  the  simulation  model  itself; 
l.e.  , the  combination  of  hardware  and  software  which,  given  anv  environment  defini- 
tion (data  base)  and  assigned  processing  parameters,  will  produce  a videotaped  se- 
quence v a 1 idly  simulating  the  desired  sensor  system  display  for  the  specified  flight 
path,  atmospheric  and  illumination  effects , system  parameters,  etc.  I'he  second 
part  of  the  total  effort  is  the  environment  definition  or  data  base  provided  with  the 
system,  including  the  development  of  the  software  for  automatic  transformation  of 
DMA  data  to  a terrain  model  suitable  for  processing  by  the  sensor  simulation  system. 

2.2  SENSOR  SIMULATION  DATA  BASE 


This  simulation  program  included  the  development  and  delivery  of  a complete  gaming 
area  data  base  derived  from  Defense  Mapping  Agency  Aerospace  Center  (l)MAAC) 
source  data  and  augmented  with  special  targets  of  interest.  In  addition  to  the  data 
base  delivered  with  the  system,  special  software  data  base  transformation  routines 
were  developed  for  execution  on  the  Sigma  5 computer.  These  routines  accept  DMAAC 
source  data  tapes  and  create  additional  data  bases  for  the  sensor  simulation  system. 

2.2.  I DELIVERED  DATA  BASE—  I'he  gaming  area  selected  for  the  initial  data  base 
is  a one-degree  latitude  bv  one-degree  longitude  area  which  includes  the  city  of  Las 
Vegas,  Nevada  and  the  surrounding  countryside  primarily  to  the  North,  East,  and  West 
of  l.as  Vegas. 

The  terrain  model  is  a "real  world"  model  consisting  of  continuously  varying  terrain 
over  the  entire  gaming  area.  1'his  terrain  modei  was  derived  entirely  from  level  1 
DMAAC  digital  source  data  for  the  area.  In  addition,  all  level  1 and  level  2 DMAAC 
cultural  (planimetricl  features  are  included  in  the  data  base  as  defined  in  the  digital 
source  data. 

Additional  cultural  features  were  added  to  the  DMA  source  data  to  provide  more  de- 
tailed features  for  meeting  research  evaluation  objectives  of  the  program.  These 
features  do  not  appear  in  the  DMA  source  data,  or  do  not  appear  with  sufficient  detail 
to  permit  level  of  detail  and  related  model  characteristics  evaluations.  Detailed  fea- 
tures added  include:  (11  an  airport  complex;  (21  an  oil  storage  area:  pH  a large  fac- 
tory complex;  (4)  a power  plant;  (f>l  a farming  area;  pH  a port  city;  and,  (7i  more 
detailed  power  polos,  bridges,  etc. 

This  data  base  is  structured  to  allow  for  display  of  different  levels  of  detail  down  to 
doors  and  windows  for  cultural  objects.  The  data  base  can  also  be  modified  updated 
under  software  control. 
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2.2.2  TRANSFORMATION  SOFTWARE  ROUTINES-General  Electric  also  developed 
and  delivered  a data  base  transformation  program  that  is  capable  of  converting  gridded 
source  data  as  furnished  by  the  DMAAC  into  a format  suitable  for  processing  by  the 
sensor  simulation  equipment.  This  software  program  was  Implemented  on  the  STARS 
Sigma  5 computer  and  can  process  any  region  of  terrain  within  the  continental  C.S.  of 
one-degree  latitude  by  one-degree  longitude  in  extent.  This  program  accepts  level  1 
source  data  prepared  by  DMAAC  on  magnetic  tape  and  creates  a terrain  model  in 
accordance  with  operator  specified  accuracy  criteria  based  upon  the  roughness  of  the 
terrain. 

2.2  SENSOR  SIMULATION  SYSTEM 

The  AEOSS  system  as  developed  by  the  General  Electric  Company  is  depicted  in 
Figure  1.  All  scene  generation  begins  within  the  STARS  Sigma  5 computer,  passes 
to  the  two  PUP  11/45  computers,  then  to  the  special  purpose  hardware  modules. 

Once  the  special  hardware  processing  is  accomplished,  a complete  scene  is  loaded 
into  the  scene  memory  and  then  recorded  on  the  video  disk.  When  the  video  disk 
is  fully  loaded  with  600  frames  of  video  data,  the  v>.’.eo  disk  sequence  is  transferred 
to  a video  tape  unit  where  longer  sequences  are  assembled.  Playback  in  real  time 
from  both  the  video  disk  and  video  tape  is  possible  on  a CRT  which  is  also  part  of  the 
AEOSS  system.  As  each  scene  is  generated,  it  is  also  displayed  on  the  CRT  to  allow 
operator  viewing  of  each  frame  as  the  sequence  is  prepared. 

2.3. 1 SENSOR  SIMULATION  SYSTEM  EQUIPMENT— Equipment  elements  of  this 
design  configuration  fall  into  three  major  categories;  A FURL  STARS  facility  equip- 
ment, General  Electric  designed  equipment  and,  vendor  equipment  purchased  by 
General  Electric  and  integrated  into  the  system.  Major  equipment  units  are  shown  in 
Figure  2.  The  relation  of  this  equipment  to  the  STARS  Sigma  5 is  described  in  the 
following  paragraphs. 

2.3. 1.1  STARS  Sigma  3 Equipment— The  Air  Force  Human  Resources  Laboratory 
STARS  facility  equipment  available  for  this  program  consisted  of  a Xerox  Data  Sys- 
tem Sigma  5 Central  Processing  Unit  (CPU),  core  memory,  and  numerous  peripherals 
controlled  via  a Multiplexing  Input  Output  Processor  (MlOP).  The  CPU  and  MIOP 
each  communicate  with  memory  on  a private  bus  connected  to  both  memory  banks 
through  memory  ports.  The  fastest  port,  usually  referred  to  as  Port  C,  on  each  bank 
is  connected  to  the  CPU.  This  port  is  preselected  by  a memory  bank  when  no  memory 
cycle  is  in  progress,  thus  creating  a shorter  selection  interval  than  can  be  achieved 
by  other  ports.  A second  port.  Port  H.  services  peripheral  devices  by  means  of  the 
MIOP.  Port  11  has  a higher  priority  than  Port  C and  will  therefore  be  serviced  first 
in  a situation  where  both  memory  ports  are  receiving  requests  for  service. 

The  MIOP  provides  independent  control  of  data  transfers  between  memory  and  periph- 
eral devices  by  activating  one  or  more  device  controllers  attached  to  its  signal  bus. 
The  basic  MIOP  contains  eight  subchannels  each  of  which  accommodates  one  device 
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controller.  The  MIOP  can  control  and  sequence  the  I/O  operations  of  any  number  of 
its  associated  controllers  simultaneously,  allowing  the  CPU  to  concentrate  on  program 
execution.  Any  events  which  require  CPU  Intervention  are  brought  to  the  attention  of 
the  CPU  by  means  of  the  interrupt  system.  The  maximum  combined  data  transfer 
rate  of  all  device  controllers  operating  simultaneously  through  one  MIOP  is  approx- 
imately 400,000  bytes  per  second. 

In  order  to  interface  the  PDP  11/45  computers  described  in  paragraph  2.3. 1.2  to  the 
existing  STARS  Sigma  5,  additional  equipment  was  added  to  the  STARS  facility.  This 
additional  equipment  consisted  of  a second  MIOP,  three  memory  port  expansion  kits, 
and  two  device  subcontrollers.  The  additional  MIOP  was  required  due  to  the  heavy 
loading  of  the  already  existing  MIOP.  AFHRL  also  expanded  the  Sigma  5 core  mem- 
ory; thus,  the  need  for  three  memory  port  expansion  kits.  Two  device  subcontrollers 
were  added  so  that  the  Sigma  5 could  communicate  directly  with  both  of  the  PDP  11/45 
computers. 

2. 3. 1.2  PDP  11/45  Computers— Two  PDP  11/45  computers  were  procured  by  Gen- 
eral Electric  to  supplement  the  computational  capability  of  the  Sigma  5 and  reduce  the 
per  scene  processing  time.  Each  computer  of  Figure  1 consists  of  a central  processor 
unit,  a floating  point  processor,  a DECwriter  console,  a programmer  console,  and  a 
4-level  automatic  priority  interrupt.  Computer  A also  has  64K  of  core  memory,  a 
2.5  million  byte  disk  cartridge  drive  and  controller,  a second  disk  drive  with  a non- 
removable, dual  density  disk,  a dual  floppy  disk,  and  a 9-track  magnetic  tape  trans- 
port and  control  unit.  Computer  B has  48K  of  core  and  a single  floppy  disk.  The  com- 
plete configuration  also  includes  seven  (7)  DR11-B  interface  units  configured  as  shown 
in  Figure  1. 

This  minicomputer  system  is  configured  to  allow  direct  communication  between  PDP 
computers,  with  the  Sigma  5 computer,  and  to  all  special  purpose  hardware  modules. 

A Sigma  5 independent  operating  mode  is  also  possible  wherein  edge  controls  words 
are  recorded  on  magnetic  tape  by  the  Sigma  5.  The  Sigma  5 edge  control  word  tape, 
containing  many  frames  of  data,  can  then  be  transferred  to  the  PDP  magnetic  tape 
unit  and  scenes  can  be  generated  without  direct  interfacing  with  the  Sigma  5. 

2.3. 1.3  Special  Purpose  Logic  and  Recording  Equipment— The  special  purpose  logic 
and  recording  equipment  and  its  points  of  interface  to  the  PDP  11/45  computers  are 
depicted  in  Figure  3.  The  computational  functions  implemented  in  special  purpose 
logic  consist  of  the  orderer  function,  the  video  assembler  function,  two  video  com- 
biner functions,  an  edge  smoothing  function,  and  a sensor  transfer  function. 

The  orderer  logic  orders  the  element  numbers  corresponding  to  the  projected  data 
base  edge  intersections  with  each  raster  line  into  ascending  numerical  order.  Up  to 
512  such  intersections  can  be  ordered  for  each  raster  line. 
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I’ho  video  assembler  logic  receives  the  ordered  edge  intersections  from  the  orderer 
logic,  resolves  priority  conflicts,  and  outputs  only  the  edge  intersections  which  are 
visible  within  the  scene.  Prior  to  this  point  edge  intersections  observed  by  nearer 
objects  must  also  be  processed.  Note  that  two-dimensional,  three-dimensional,  and 
fog  edges  are  separately  processed  to  this  point. 

The  video  combiner  logic  combines  first  the  two-dimensional  and  fog  edges,  then  adds 
the  three  dimensional  edges,  to  end  up  with  a single  tone  for  each  picture  element. 
Thus  at  tlvis  point  a complete  I'll!  type  picture  (without  edge  smoothing)  has  been 
created. 


It  the  system  operator  has  selected  edge  smoothing,  the  raster  lines  and  element  num- 
bers referred  to  in  the  preceding  paragraphs  are  actually  "sublines"  and  "subelements." 
That  is,  more  raster  lines  and  raster  elements  will  have  tie  on  computed  than  will  ul- 


timately be  displayed.  The  edge  smoothing  logic  accepts  the  data  for  the  subelements 
on  each  subline  (element  number,  tone,  and  delta  tone)  and  generates  smoothed 


data,  free  of  staireasing  effects  for  those  raster  lines  to  be  ultimately  displayed,  lip 
to  111  sublines  and  subelements  of  smoothing  can  be  specified  by  the  operator. 


The  final  stage  of  special  logic  is  the  sensor  transfer  function  logic  which  applies  a 
weighted  matrix  transfer  function  and  sonsor  noise  to  simulate  the  transfer  character- 
istics of  the  particular  sensor  being  simulated.  The  final  tone  assigned  to  each  ele- 
ment is  thus  computed  based  upon  a weighted  average  of  the  tone  of  the  element  itself 
and  the  tones  of  up  to  24  of  its  adjacent  neighbors.  Moth  the  number  of  neighboring 
elements  to  be  considered  and  the  weight  assigned  to  each  element  tone  is  specified 
by  the  operator.  The  operator  can  also  specify  the  amount  of  sensor  noise  to  be  added 
to  the  video. 


At  this  point,  one  raster  line  of  video  is  complete  and  it  is  then  loaded  into  the  scene 
memory.  The  scene  memory  is  a random-access  semiconductor  memory  built  by 
National  Semiconductor.  This  memory  is  configured  to  store  one  complete  frame 
(scene)  of  N-blt,  digital  video  data  consisting  of  up  to  ISO  raster  lines  of  040  elements 
per  raster  line.  Thus,  each  picture  element  can  be  one  of  250  grey  shade  levels. 

Once  a complete  frame  of  video  data  has  been  written  onto  the  scene  memory,  that 
scene  is  recorded  on  the  video  disk  recorder  and  also  displayed  on  the  i'll  1'.  The 
video  disk  recorder  thus  accumulates  consecutive  frames  of  video  data  for  subsequent 
playback  in  real  time.  The  video  disk  used  in  this  system  is  an  Am  pox  Model  MD-400 
which  utilizes  a dual  surface  disk.  Dp  to  000  tracks  of  data  can  be  recorded  where 
each  track  coincides  with  one  frame  of  data.  Playback  at  the  standard  TV  rate  of  30 
frames  'sec  allows  for  up  to  a 20-second  real-time  sequence  to  be  recorded  before  re- 
peating.  Kaeh  successive  frame  of  data  Is  precisely  positioned  with  respect  to  the 
preceding  frame  such  that  a continuous  sequence  is  perceived  upon  playback.  1'he 
Atnpex  MD-400  can  also  display  any  single  frame  of  data  as  a static  scene  from  any 
scene  recorded  on  the  disk. 
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When  dynamic  sequences  longer  than  20  seconds  are  desired,  such  sequences  are 
accumulated  from  consecutive  20-second  sequences  on  a video  tape  recorder.  The 
video  tape  recorder  is  an  Ampex  Model  VPR-1.  The  VPR-1  is  a precision  device 
that  allows  near  perfect  matching  of  consecutive  sequences  to  create  longer  sequences. 
Thus,  any  number  (up  to  one  hour  of  real-time  video)  of  20-second  sequences  can  be 
transferred  to  the  VPR-1  and  precisely  positioned  with  respect  to  the  end  of  the  last 
20-minute  sequence. 

The  entire  recording  sequence  from  scene  memory  through  the  video  tape  recorder  is 
under  the  automatic  control  of  a special  controller  which  receives  all  its  mode  com- 
mands from  the  master  PDP  11/45  computer.  That  is,  no  operator  control  is  required 
beyond  an  initial  selection  of  the  number  of  frames  of  data  to  be  recorded. 

2.3.2  SENSOR  SIMULATION  SYSTEM  OPERATION— Preceding  paragraphs  describe 
the  sensor  simulation  equipment  configuration  along  with  a brief  outline  of  the  role  of 
each  equipment  unit.  The  following  paragraphs  describe  the  detailed  assignment  of 
computational  functions  to  the  Sigma  5,  the  two  PDP  11/45's  and  the  special  logic 
modules,  including  typical  data  flow  for  generating  a single  frame  of  video  data. 

2.3.2. 1 Allocation  of  Functions— A detailed  description  of  the  various  computational 
functions  which  are  performed  is  contained  in  the  system  and  software  report  prepared 
by  General  Electric  under  this  contract.  The  various  computational  functions  are 
grouped  into  general  categories  based  upon  the  organization  of  real-time,  visual  com- 
puter image  generation  systems  designed  by  General  Electric,  plus  an  additional  cat- 
egory related  to  airborne  electro-optical  sensor  simulation.  These  functional  cate- 
gories are  labeled  Frame  I,  II,  III,  and  IV  for  simplicity.  Frame  I functions  are 
those  functions  which  must  be  performed  once  per  frame  time,  and  account  for  the 
scene-to-scene  sensor  motion  and  various  coordinate  system  rotation  calculations. 
Frame  II  functions  are  those  calculations  which  are  required  to  transform  the  numer- 
ical description  of  the  data  base  to  a set  of  edge  control  words  which  define  the  pro- 
jection of  the  data  base  onto  an  imaginary  view  window.  Frame  III  includes  all  re- 
maining functions  which  must  be  performed  to  establish  the  color  or  gray  shade  of  each 
picture  element  in  the  scene.  Primary  Frame  HI  functions  are  video  assembly,  video 
combining,  data  ordering,  and  edge  smoothing.  The  Frame  rv  functions  are  those 
unique  to  sensor  simulation  systems,  and  consist  of  the  sensor  transfer  function, 
system  noise,  and  related  sensor  system  characteristics.  With  this  categorization  of 
functions  in  mind,  the  assignment  of  computational  functions  to  the  computational  units 
can  now  be  described. 

To  achieve  the  fastest  possible  per  scene  update  rate  consistent  with  a fully  flexible 
design  and  reasonable  cost,  the  pipeline  processing  technique  (used  most  effectively 
in  real-time  simulation  systems)  was  applied  to  the  sensor  simulation  system  design. 
With  the  pipeline  processing  technique,  the  complete  set  of  computations  required  to 
develop  a scene  are  assigned  to  separate,  sequential  processing  units.  Each  scene  is 
partially  processed  by  the  first  computational  unit,  then  the  partially  processed  scene 
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data  is  passed  on  to  the  next  computational  unit.  While  the  second  computational  unit 
performs  further  processing  on  the  first  scene,  the  first  computational  unit  begins 
processing  the  next  scene.  Any  number  of  sequential  processing  units  can  be  used, 
subject  only  to  the  number  of  simple  divisions  which  can  be  made  for  the  total  scene 
computational  task.  For  this  sensor  simulation  system,  two  stages  of  pipeline  pro- 
cessing were  chosen  with  the  first  stage  being  the  Sigma  5,  and  the  two  minicomputers 
ami  special  purpose  logic  comprising  the  second  stage  of  processing.  It  should  be 
noted  that  the  time  to  generate  a single  scene  (and  the  first  scene  in  a sequence  of 
scenes)  is  the  total  additive  time  of  each  processing  stage.  Once  the  pipeline  is  filled 
(in  this  case  it  takes  two  consecutive  scenes)  however,  a new  complete  scene  is  ready 
for  display  in  the  processing  time  of  the  slowest  processing  stage.  The  average  scene 
update  rate  for  a large  number  of  sequential  scones  therefore  approaches  the  time 
used  by  the  slowest  stage  of  pipeline  processing. 

In  this  system,  all  Frame  1 and  Frame  II  functions  are  assigned  to  the  Sigma  5 com- 
puter. The  existing  Sigma  programs  were  modified  to  provide  more  efficient  execu- 
tion by  setting  up  larger  core  buffers,  utilizing  double  buffering  techniques  to  reduce 
disk  accesses,  and  taking  better  advantage  of  scene  statistics  to  minimize  running 
time.  The  Frame  III  and  Frame  IV  functions  were  divided  between  the  special  purpose 
logic  and  the  two  PDF  11/45  computers.  The  orderer,  video  assembler/combiner, 
and  edge  smoothing  are  Frame  III  functions  assigned  to  hardware  and  the  sensor  noise 
and  sensor  transfer  functions  are  Frame  IV  functions,  also  assigned  to  hardware. 

This  hardware  augmenting  of  the  PDP  11/45's  was  essential  in  order  to  achieve  rea- 
sonable scene  update  rates  because  of  the  time-consuming  nature  of  these  functions. 

It  should  be  noted,  however,  that  the  flexibility  of  the  simulation  is  maintained  since 
these  functions  must  be  performed  by  any  sensor  simulation  approach  and  the  hard- 
ware is  designed  to  be  software  programmable  in  terms  of  degree  of  smoothing,  sen- 
sor transfer  function,  and  amount  of  sensor  noise. 

It  should  also  be  noted  that  the  two  PDP  11/45's  are  configured  to  operate  in  parallel, 
performing  exactly  the  same  functions  for  different  raster  lines,  tine  PDP  operates 
on  even  raster  lines  while  the  second  PDP  operates  on  the  odd  raster  lines.  Thus, 
both  parallel  and  pipeline  processing  techniques  art*  utilized  in  this  design. 

2.3.2. 2 Data  Flow  Sequence— Data  flow  through  the  system  originates  in  the  Sigma  5 
computer.  Processing  begins  with  the  reading  and  interpretation  of  the  operator  in- 
puts which  define  the  parameters  controlling  the  scene  to  be  generated.  The  Frame  1 
functions  are  then  performed  by  three  separate  software  routines.  The  first  routine 
generates  the  Scene  Data  Base  file  using  the  Extended  Data  Base  file  and  the  control 
parameters  input  by  the  operator.  The  Scene  Data  Base  file  contains  information  only 
for  that  portion  of  the  Extended  Data  Base  file  that  is  within  the  field  of  view  as  defined 
by  the  operator  input  data.  The  Extended  Data  Base  file  contains  all  the  information 
defining  the  complete  gaming  area  data  base  as  described  in  paragraph  2.2. 1.  As  the 
Scene  Data  Base  file  is  created,  a list  of  the  range  from  the  selected  viewpoint  to  each 
face  of  each  object  in  the  scene  data  base  is  also  created.  For  three-dimensional  cul- 
tural objects,  the  object  centroid  range  is  assigned  to  all  faces  of  each  object. 
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The  next  routine  determines  the  relative  priority  of  all  the  three-dimensional  cultural 
objects  within  the  field  of  view.  For  priority  purposes,  a three-dimensional  cultural 
object  is  considered  within  the  field  of  view  if  any  portion  ol  an  encompassing  sphere 
is  within  the  field  of  view.  For  this  purpose  both  an  object  centroid  and  object  radius 
are  defined  as  part  of  the  Extended  Data  Base  file. 

The  final  Frame  I routine  generates  a combined  face  priority  list  for  all  terrain  and 
object  faces  within  the  field  of  view.  This  Is  accomplished  by  modifying  the  face  range 
list  generated  earlier,  such  that  the  assigned  range  value  for  each  three-dimensional 
cultural  object  (and  all  its  faces)  varies  inversely  with  its  relative  priority.  That  is, 
the  range  values  are  forced  to  increase  as  relative  priority  decreases.  In  addition, 
the  range  value  for  each  terrain  face  is  forced  to  be  greater  than  the  range  to  any  three- 
dimensional  cultural  objects  that  is  superimposed  on  that  terrain  face.  In  this  manner 
a range  list  is  created,  for  all  faces  within  the  field  of  view,  which  varies  inversely 
with  the  priority  of  the  face  in  the  event  of  priority  conflicts.  Finally  this  range  list 
is  ordered  by  increasing  range  to  produce  a unique  priority  number,  based  upon  the 
position  in  the  ordered  list,  for  each  face  in  the  scene.  This  priority  list  is  retained 
in  memory  for  use  by  the  Frame  II  routines  in  constructing  Edge  Control  Words. 

It  should  be  noted  that  the  creation  of  the  combined  face  priority  list  required  the  de- 
velopment of  a new  algorithm  for  this  program.  The  previous  all  software  programs 
operated  on  an  object  priority  basis  rather  than  a face  priority  basis.  For  an  object 
priority  scheme  to  work,  convex  objects  are  required.  Construction  of  convex  objects 
to  define  terrain  from  DMAAC  source  data  is  not  practical  with  automatic  software 
techniques;  thus,  a new  priority  routine  was  required. 

Once  the  priority  list  for  all  faces  is  complete,  the  Sigma  5 begins  to  execute  the 
Frame  II  routines.  These  Frame  II  routines  are  the  same  routines  implemented  in 
the  all  software  model,  except  that  the  routines  were  modified  to  operate  on  a face 
priority  basis  rather  than  an  object  priority  basis.  The  output  format  of  the  Edge  Con- 
trol Words  generated  by  the  Frame  II  routines  was  also  changed  to  be  compatible  with 
the  16-bit  PDP  11/45  computers. 

The  input  to  the  Frame  II  routines  is  the  Scene  Data  Base  and  face  priority  list  de- 
scribed earlier.  In  general,  the  Scene  Data  Base  and  priority  list  will  remain  the 
same  for  several  consecutive  frames,  when  the  viewpoint  moves  very  little  between 
frames.  Thus,  provisions  are  made  to  allow  the  operator  to  specify  the  number  of 
consecutive  frames  of  Edge  Control  Words  to  be  generated  by  Frame  II  before  the 
Frame  I calculations  are  updated.  At  the  same  time,  parameters  such  as  viewpoint, 
bo  resight,  time  of  day,  or  any  other  control  inputs  can  be  specified  to  change  at  any 
particular  frame  or  at  every  frame. 


The  Frame  II  routines  generate  an  Edge  Control  Word  for  each  edge  of  each  face  in 
the  scene  data  base.  These  Edge  Control  Words  consist  of  the  projections  of  the  data 
base  edges  to  the  image  plane.  Each  edge  is  defined  by  the  raster  line  and  element 
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number  pairs  at  which  its  end  point  projections  pierce  the  view  plane,  the  slope  of  the 
edge  projection,  and  various  other  data  including  face  tones,  priority,  etc. 

All  data  files  used  and  created  by  the  Sigma  5 Frame  I and  Frame  D routines  are  main- 
tained on  the  Sigma  5 disk.  The  Frame  II  Edge  Control  Word  output  file  can  be 
written  on  magnetic  tape  for  later  input  to  the  PDP  11/45's  or  sent  directly  to  the 
PDP's  for  Frame  III  processing. 

The  Frame  III  processing  in  the  PDP  computers  is  started  by  initializing  the  control 
parameters  (from  operator  inputs)  for  the  PDP  edge  generator  routines  and  providing 
Edge  Control  Word  data,  either  directly  from  the  Sigma  5 or  from  magnetic  tape. 

When  the  PDP  11/45's  receive  data  directly  from  the  Sigma  5,  the  two  PDP's  work  in 
parallel  to  produce  edge  crossing  data  for  each  of  their  respective  raster  lines.  The 
master  PDP  produces  data  for  even-numbered  raster  lines,  while  the  slave  computer 
produces  data  for  the  odd-numbered  raster  lines.  When  Edge  Control  Word  data  is 
received  from  magnetic  tape,  the  master  PDP  reads  the  data  into  its  memory  and  then 
shares  the  data  with  the  slave  computer  as  they  produce  edge  crossings  for  their  re- 
spective raster  lines. 

The  output  of  both  computers  is  directed  to  the  orderer  function  at  the  head  of  the 
hardware  processor  pipeline.  The  orderer  logic  alternately  selects  data  from  the  two 
PDP's,  thereby  gathering  data  for  all  raster  lines  in  the  proper  sequence.  Thus,  the 
two  PDP  computers  accomplish  the  edge  selection  process,  determine  active  edges, 
and  compute  edge  data  (element  number,  tone,  and  tone  gradient)  for  each  raster  line 
in  turn. 

The  orderer  then  arranges  the  edges  in  increasing  element  number  sequence,  and  the 
video  assembler  resolves  priority  conflicts  and  outputs  only  actually  visible  edges. 

It  provides  for  each,  the  element  or  subelement  number  at  which  the  edge  begins  to 
control  the  tones  on  the  raster  line,  the  tone  at  that  element,  and  the  tonal  gradient 
continuing  along  the  line.  In  this  manner  the  scene  is  processed  on  a picture-element- 
by-picture-element  basis  and  assembled  on  a raster-line-by-raster-line  basis.  If  edge 
smoothing  is  being  applied,  the  assembled  raster  lines  (sublines)  are  passed  to  the 
edge  smoothing  logic,  then  passed  to  the  transfer  function  logic.  The  data  from  the 
edge  smoothing  logic  is  the  data  for  picture  elements  and  raster  lines  to  be  displayed. 
That  is,  the  subelement  and  subline  data  have  been  used  to  generate  smoothed  data  for 
the  output  raster  lines  and  the  subelement  and  subline  data  are  then  discarded.  The 
data  from  the  transfer  function  logic  are  output  on  a line-by-line  basis,  ready  for 
display. 

From  this  (K)int,  the  completed  raster  lines  are  written  directly  onto  the  scene  mem- 
ory. The  scene  memory  is  configured  to  store  a complete  frame  of  data  with  8 bits 
of  video  per  picture  element.  Complete  frames  are  assembled  on  a raster-line  by 
raster-line  basis  in  the  scene  memory,  then  the  entire  frame  is  transferred  to  the 


video  disk.  When  the  video  disk  is  fully  loaded  with  GOO  frames  of  data,  its  contents 
are  transferred  to  the  video  tape  unit  to  create  longer  sequences. 

As  the  Sigma  5 completes  its  processing  of  the  first  scene,  it  immediately  begins  to 
process  the  next  scene  such  that  at  any  given  instant  in  time,  two  scenes  are  simul- 
taneously being  processed  in  the  sensor  simulation  system.  While  the  Sigma  5 works 
on  one  scene,  the  PDP's  are  processing  the  scene  previously  processed  by  the  Sigma 5 
and  providing  edge  crossing  data  to  the  special  purpose  hardware  logic.  Thus,  the 
two  PDP's  operate  in  parallel  with  one  another,  while  the  Sigma  5,  the  parallel  PDP's, 
and  the  special  purpose  logic  form  a pipeline  processor  chain  each  performing  a por- 
tion of  the  required  scene  processing. 

2. 3. 2. 3 Software  Design— The  all  software  routines  implemented  on  the  AFHRL 
STARS  facility  under  an  earlier  contract,  served  as  the  basis  for  the  current  sensor 
simulation  system  software.  These  existing  routines  were  reorganized  in  order  to 
optimize  execution  time.  By  taking  advantage  of  scene  statistics,  the  average  execu- 
tion time  for  a scene  was  significantly  improved.  Since  the  algorithms  were  already 
known  to  be  mathematically  correct,  the  majority  of  the  software  effort  was  directed 
toward  achieving  more  efficient  operation.  Some  new  routines/algorithms  were  de- 
veloped to  provide  a face  priority  scheme  and  also  to  provide  fading  across  individual 
faces  of  selected  three-dimensional  objects.  Minor  changes  were  also  required  in 
existing  routines  to  accommodate  the  face  priority  approach. 

Sigma  5 software  consists  primarily  of  the  previous  Frame  I and  Frame  II  software 
routines  from  the  all  software  model.  The  Frame  II  routines  have  double  buffering 
for  all  I/O  operations  such  that  software  execution  can  proceed  in  parallel  with  the 
I/O  operations  once  they  have  been  initiated.  Since  a significant  portion  of  the  current 
Frame  I and  Frame  II  time  is  consumed  in  I/O  operations,  significant  speed-up  of 
execution  time  is  achieved  via  this  parallel  organization. 

All  Sigma  5 software  routines  are  written  in  the  Fortran  language,  with  the  exception 
of  special  input/output  routines  which  are  written  in  assembly  language.  The  deci- 
sion to  use  Fortran  was  made  to  enhance  the  use  and  modification  of  the  software  by 
the  users.  Very  little  penalty  in  execution  time  resulted  due  to  the  efficiency  of  the 
Sigma  Fortran  compiler.  In  the  case  of  I/O  routines,  however,  the  standard  Fortran 
routines  are  necessarily  very  general  purpose  in  nature  and  thus  not  efficient  in  per- 
forming specific  and  limited  I/O  tasks. 

The  software  routines  implemented  on  the  PDP  computers  consist  of  previously  devel- 
oped Frame  III  edge  generation  routines.  Of  course,  special  routines  were  required 
to  accommodate  data  exchanges  between  the  Sigma  and  the  PDP's,  data  output  to  the 
special  purpose  hardware,  alternate  raster  line  processing  by  the  two  PDP's,  and  to 
control  the  recording  process. 
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As  was  the  case  with  the  Sigma  software,  all  routines  except  special  I/O  routines, 
were  written  in  the  Fortran  language.  Double  buffering  of  data  files  at  both  the  input 
and  the  output  of  the  PDF  processing  was  also  employed  in  order  to  overlay  I/O  time 
with  processing  time. 

2. 8. 2. 4 Hardware  Design— The  video  disk,  video  tape  unit,  anil  the  P1)P  computers 
and  i>eriphcruls  arc  provided  with  their  own  enclosures  by  the  equipment  vendors. 
Packaging  of  the  GUI'  display,  tin'  scene  memory  and  the  special  purpose  hardwure 
logic  was  provided  by  tieneral  Electric.  The  CltT  and  scene  memory  are  mounted 
in  one  standard  equipment  rack  and  interfaced  to  other  equipment  units  via  General 
Electric  designed  cables  and  interface  logic. 

An  additional  equipment  rack  is  required  for  the  special  purpose  logic  designed  by 
General  Electric.  Design  techniques  and  packaging  are  based  upon  the  General 
Electric  designs  for  real-time  visual  and  radar  simulation  programs. 

Physical  and  functional  arrangement  of  the  special  purpose  hardware  within  the  equip- 
ment enclosures  has  been  selected  to  meet  the  objectives  of  high  reliability,  easy 
maintenance  and  maximum  utilization  of  space.  The  enclosures  feature  plug-in  circuit 
boards,  hinged  card  file  assemblies,  power  supplies,  power  control  devices  and  cool- 
ing air  blowers. 

Circuits  used  within  the  special  purpose  processing  equipment  are  packaged  on  plug- 
in boards.  The  boards  are  approximately  5.5"  \ U.75"  in  size  with  a design  capacity 
of  40  integrated  circuit  devices  and  a 140  pin  edge  connector,  of  which  12  are  pre- 
assigned for  ground  and  power,  leaving  128  available  for  signals.  Extraction  devices 
are  provided  on  each  board  eliminating  the  need  for  special  tools  for  Insertion  or 
removal.  The  circuit  boards  used  are  solderless  wrapped  boards  of  a universal  de- 
sign which  lends  itself  to  any  circuit  configuration  by  means  of  its  capability  of  being 
solderless  wrapped,  either  by  machine  or  manuully. 

The  circuit  boards  are  plugged  into  a card  file  assembly,  commonly  called  a "swing 
frame"  because  it  is  hinged  on  one  side  for  access  to  the  backplane  wiring,  and  such 
devices  that  may  be  mounted  behind  the  swing  frame.  The  swing  framo  is  composed 
of  the  circuit  board  guides  which  assure  proper  line  up  of  the  boards  ami  their  corres- 
ponding circuits;  the  backplane  which  contains  all  the  circuit  board  connectors  and 
their  Interconnections;  and  banks  of  cooling  fans  located  top  and  bottom,  to  provide  a 
continuous  air  flow  during  operation  to  all  the  circuit  boards. 

The  principal  part  of  the  swing  frame  is  the  backplane.  It  Is  a two  sided  copper-clad 
epoxy  glass  laminate,  which  is  precision  machined  to  mount  the  board  connectors  and 
Interconnections  devices  with  sufficient  accuracy  to  permit  automatic  wrapping.  One 
side  of  the  backplane  serves  as  a power  plane  and  the  other  as  a ground  plane.  Power 
and  ground  connections  are  carried  to  all  circuit  boards  by  means  of  direct  connec- 
tions between  board  connectors  and  the  planes.  Power  and  ground  is  in  turn  carried 
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to  tho  swing  frame  by  a dual  sot  of  flexible  heavy  duty  cables  which  are  inserted 
bolted  to  the  backplane.  Signals  are  carried  to  and  from  the  backplane  with 
zero-insertion  force,  lever  actuated  9H  pin  connectors  that  are  solderless  wrapped  to 
the  circuit  board  connectors. 

A coordinate  system  of  row  and  column  designators  is  used  to  identify  each  card  slot; 
such  information  is  prominently  displayed  on  the  face  of  the  swing  frame.  To  assist 
in  properly  inserting  the  circuit  boards,  decals  are  mounted  on  the  face  of  the  swing 
frame  that  list  the  circuit  board  slot  and  board  identification  code.  The  board  identi- 
fication code  is  printed  on  the  ejector  and  thus  is  readily  visible  on  all  boards  whether 
mounted  or  unmounted. 

The  enclosure  used  w ill  accommodate  up  to  two  swing  frames.  The  arrangement  is 
such  that  full  access  to  any  circuit  board  is  possible  by  opening  the  enclosure  door. 
Filtered  cooling  air  is  drawn  in  through  intakes  located  in  the  lower  portion  of  the  en- 
closure and  discharged  through  perforated  panels  in  the  top,  thus  maintaining  a posi- 
tive pressure  during  equipment  operation  and  minimizing  dust  accumulation  within. 
Standard  1 2<>  volt,  (>0  cycle  power  is  the  only  facility  power  utilized  as  logic  power 
supplies  are  contained  in  the  equipment  rack. 

3.0  RESULTS  AND  CONCLUSIONS 

3.1  RESULTS 

The  results  of  this  program  can  best  be  measured  in  terms  of  how  well  the  objectives 
at  the  program  outset  are  met  by  the  system  delivered.  The  objective  was  to  develop 
and  deliver  a fast,  nonreal-time  sensor  simulation  image  generation  system  with  real- 
time dynamic  playback  capability  to  be  usable  by  A FURL  as  a research  tool.  The  sys- 
tem was  also  to  retain  maximum  flexibility’  to  evaluate  different  algorithms,  and  pro- 
vide the  capability  to  create  and  record  dynamic  sequences  for  playback  in  real  time. 

In  terms  of  these  general  objectives  the  program  is  an  unqualified  success.  Results 
obtained  during  the  test  and  evaluation  phase  have  proven  the  flexibility  of  the  system. 
The  programmability  of  the  functions  implemented  in  hardware  allows  great  latitude 
in  evaluating  different  sensor  characteristics  and  different  edge  smoothing  implemen- 
tations. The  operator  input  parameters  allow  setup  of  any  scene  parameters  desired 
and  permit  unconstrained  selection  of  viewpoints  within  the  data  base.  In  addition,  the 
capability  is  provided  to  bypass  the  hardware  algorithms  and  replace  those  functions 
with  any  desired  software  algorithm,  should  even  greater  algorithm  flexibility  be 
desired. 

Dynamic  sequences  have  been  recorded  which  demonstrate  the  ability  of  the  system  to 
create  long  dynamic  sequences  for  playback  in  real  time.  Moth  the  quality  of  the  in- 
dividual frames  of  video  and  the  quality  of  the  overall  sequences  have  proven  satisfac- 
tory for  meeting  the  program  objectives. 
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Hie  time  required  to  generate  complex  scones  with  high  order  transfer  functions  has 
boon  reduced  by  a factor  of  l>ctvvccn  sixty  to  one  and  ninety  to  one,  depending  upon  the 
complexity  ot  the  selected  scene,  when  compared  to  the  all  software  model.  The  time 
penalty  paid  for  high  order  edge  smoothing  has  also  boon  greatly  reduced.  It  should 
be  noted,  however,  that  for  a given  scene,  the  scene  generation  time  is  directly  re- 
lated to  the  order  ot  edge  smoothing  selected.  It  should  also  be  noted  that  the  scene 
generation  time  is  now  completely  independent  of  the  transfer  function  applied. 

In  spite  ot  the  tremendous  reduction  in  the  time  required  to  generate  a frame  of  video, 
the  s|H'cific  design  goal  ot  It'  seconds  or  less  for  selected  complex  scenes  was  not 
reached.  While  many  reasonably  complex  scenes  can  bo  generated  in  less  than  10 
seconds,  an  average  scene  generation  time  for  scenes  from  the  delivered  data  base  is 
probably  closer  to  JO  seconds. 

In  the  early  test  and  evaluation  phase,  scene  generation  times  of  up  to  several  minutes 
were  not  uncommon.  This  led  to  an  evaluation  of  where  time  was  lost  and  how  faster 
scene  generation  times  could  be  achieved.  The  somewhat  surprising  result  of  this 
evaluation  was  that  the  major  factor  pacing  scene  generation  time  was  the  size  of  the 
core  memory  data  buffers  in  the  Sigma  a ami  PUP  computers,  t hat  is,  the  calcula- 
tion time  involved  was  at  a satisfactory  level  and  I O transfer  time  was  not  a maior 
factor.  Hie  real  problem  was  the  large  number  of  data  accesses  required  for  com- 
plex scenes  due  to  the  size  ot  the  core  memory  buffers  in  relationship  to  the  total  data 
required  to  generate  a complex  scene.  It  was  not  that  the  buffers  were  small,  but 
rather  that  the  data  requirements  per  scene  were  enormous.  Once  the  problem  was 
isolated,  the  obvious  solution  was  to  create  larger  buffers.  I’nfortunately  all  POP 
core  memory  was  already  fully  allocated  to  buffers  and  program  storage.  Thus,  it 
was  necessary  to  add  additional  core  memory  to  the  POP  configuration.  Hy  adding 
one  additional  Ink  core  memory  module  to  one  of  the  PUP  computers  ami  allocating  all 
ot  the  additional  core  to  the  edge  control  word  buffers,  a four-to-one  reduction  in  scene 
generation  time  was  achieved  lor  selected  complex  scenes.  Allocation  of  additional 
Sigma  f>  co ix'  to  the  sensor  simulation  task  also  resulted  in  major  speed-ups.  While 
it  would  be  possible  to  achieve  still  further  reductions  in  scent'  generation  time  with 
still  larger  buffers,  the  practical  limit  has  been  reached.  Pse  of  more  Sigma  core 
would  ettectively  eliminate  all  other  Sigma  processing  tasks  when  the  sensor  Simula 
tit'n  system  is  in  opt' rat  ion.  Addition  of  more  PUP  core  to  the  system  would  require 
more  core  for  both  PUP  computers  and  result  in  major  changes  in  the  PUP  configura- 
tion tt'  accommodate  the  additional  core.  l'he  current  scene  generation  time  is  not 
unreasonable  for  even  the  complex  scenes  and  for  the  loss  complex  scenes,  no  reduc- 
tion m scene  generation  time  would  result  from  the  use  of  larger  buffers  in  any  event. 

In  summarv  all  maior  program  obiecttves  with  the  exception  of  the  scene  generation 
time  were  fully  met  by  the  system,  the  longer  specific  scene  generation  time  does 
not  detract  from  the  overall  system  image  generation  pv'rformance , but  simply  require 
more  time  for  the  generation  ot  evaluation  scenes. 
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It  is  recommended  that  future  similar  programs  planned  lor  heavy  usage  anil  requir- 
ing extensive  computer  resources  be  configured  as  stand-alone  systems,  l’he  AF11RI 
STARS  facility  is  required  to  support  a large  number  of  simulation  activities.  When 
the  Sensor  Simulation  System  is  in  operation,  it  requires  such  a large  share  of  the 
S TARS  resources  that  efficient  operation  of  other  simulation  programs  is  precluded. 

| 

A stand-alone  sensor  simulation  system  would  either  require  more  computing  equip- 
ment at  a higher  cost,  or  require  more  time  on  a por-scene  basis.  It  the  slower 
per-scene  computation  time  is  acceptable,  given  the  full-time  availability  of  a stand- 
alone system,  then  a stand-alone  system  would  actually  Ik1  a lower  cost  system. 

Should  the  same  (x*r  scene  time  goals  tx‘  considered  essential,  the  higher  cost  id  the 
required  general  purpose  computational  equipment  could  still  lx*  partially  offset.  For 
example,  the  cost  of  integrating  the  STARS  equipment  and  the  sensor  simulation 
equipment  would  not  be  incurred.  This  would  save  both  manpower  and  equipment 
costs.  It  is  also  expected  that  operating  costs  would  be  lower  by  elimination  ol  at 
least  some  ot  the  requirements  for  premium  time  STARS  operation. 

Note  that  this  recommendation  should  bo  considered  only  when  existing  computational 
equipment  is  heavily  utilized  or  when  the  new  program  being  planned  will  require  ex- 
tensile resources  and  usage  of  the  existing  equipment. 

It  is  also  recommended  that  a full  complement  of  development  peripherals  be  included 
with  any  general  purpose  computer  system  included  in  future  simulation  programs. 
Should  such  systems  be  configured  as  stand-alone  systems,  this  is  mandatory.  1 von 
when  such  a system  is  integrated  with  an  existing  computational  system  which  includes 
ilevelopment  peripherals,  however,  any  additional  general  purpose  computing  equip- 
ment should  include  development  peripherals  to  support  operation,  diagnostics,  and 
modifications  to  the  system.  The  additional  cost  of  such  peripherals  will  be  largely 
recovered  through  more  efficient  system  operation. 

For  any  computational  system  involving  large  quantities  of  data  where  data  through- 
put is  an  important  consideration,  provisions  must  lx>  made  for  large,  high-speed 
data  buffers.  In  such  applications,  data  access  time  due  to  insufficient  buffering  can 
often  be  a major  factor  in  data  throughput.  While  computational  speed  and  efficiency 
are  the  most  important  factors,  when  small  quantities  of  data  and  repetitive  calcula- 
tions are  involved,  data  access  becomes  equally  important  when  large  quantities  of 
data  are  also  involved.  In  such  cases  the  use  of  small  buffers,  in  an  effort  to  mini- 
mize the  cost  of  the  computer  system,  should  bo  implemented  only  when  cost  is  the 
overriding  conside ration. 
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